
Dr airings 

Applicants provide herewith a Letter to the Drawing 
Review Branch together with formal drawings for entry in the 
case subject to the approval of the Examiner. 

35 U.S.C. 103 

Claims 1-9 have been rejected under 35 U.S.C. 103(a) 
over Klein (U. S. Patent 5,845,285) in view of Geer (U. S. 
Patent 5, 930,778) . 

Applicants continue to traverse the rejection of all of 
these claims on the basis that the Examiner has not 
established a prima facie case of obviousness. The art 
references on which he relies do not suggest a combination 
which reads on applicants claims. The Examiner has in the 
rejection of these claims assembled a piecemeal 
reconstruction of prior art patents and official notice 
which could only be done if done in light of applicants' 
disclosure. Such a reconstruction or combination is based 
upon an improper hindsight view of the art after having the 
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benefit of applicants' disclosure. 

The basis of the Examiner's rejection of applicants' 
claims 1-9 appears to be based upon the premise that one of 
ordinary skill would have made the association of Geer and 
Klein, and his rejection of claims 10-11 upon the 
association of Geer and Rail. These rejections apparently 
rest on the Examiner's interpretation of Geer as teaching 
the preprocessing of invoices before introduction to a 
database, of Klein as teaching of duplicate invoice 
identification before entering into a database, and of Rail 
as teaching of net sum greater than zero for communicating a 
duplicate invoice rejection back to a vendor. 

Applicants traverse the suggestion that those of 
ordinary skill in the art would interpret Geer as teaching 
the preprocessing of invoices. Rather, Geer teaches how to 
expedite the processing of checks received by a business 
with an accompanying payment form, to reduce the time from 
receipt of the check to the time the funds are available to 
the business to use (Col. 1, lines 18-24) . 

Applicants traverse the suggestion that those of 
ordinary skill in the art would interpret Klein as teaching 
of finding duplicate invoices and interpreted it in light of 
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Geer as teaching preprocessing, Klein clearly teaches a 
method of finding duplicates after data is entered into a 
database, and thus teaches away from applicants solution to 
the problem of duplicate invoice processing. 

Applicants traverse the suggestion that those of 
ordinary skill in the art would interpret Rail as teaching 
the rejection of invoices to vendors. Rail clearly teaches 
a method to review call records to prevent a record from 
appearing twice on a bill being sent to a customer. Its 
teachings clearly indicate that after matching the call 
records, if a duplicate is found, that the duplicate goes to 
an audit file, and is not rejected back to a vendor. 

Applicants' invention provides a system and method for 
preventing duplicate invoices from entering a payment 
application (SAP) . Once an invoice is identified as a 
duplicate, it is rejected electronically and in real-time, 
automatically returned to the supplier prior to entering the 
payment application (SAP) for invoice processing. This 
enables automated error notifications (a.k.a, 824 
transactions) to be sent out EDI. An invoice is identified 
as duplicate if it is of the same vendor invoice, the same 
purchase order number, and the same item number, AND has not 
been previously washed (that is, the sum of such invoice 
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items is greater than zero.) Thus, applicants define a 
duplicate invoice as follows: 

"Referring to Figure 2, the auditing step 82 includes, 
in step 88, sorting the inbound invoices against SAP 
production tables for same vendor and same vendor 
invoice number; in step 90, sorting hits from step 88 
for same purchase order billed; in step 92, sorting 
hits from step90 for same items billed on purchase 
order; and in step 94 sorting hits from step 92 to see 
if any item identified has a net sum > 0. If an item 
has net sum ^0, it is not a duplicate and is allowed in 
steps 98 and 8 6 to be posted to the accounts payable 
data base. If an item has net sum > 0, it is a 
duplicate, and a transaction back to the vendor is 
created in steps 96 and 84 to cancel the duplicate 
invoice." (Specification, page 11, lines 4-15.) 

First, with respect to Klein. Klein relates to a 
neural network based system for auditing data in a database 
for detecting duplicate data. Data already entered into the 
database is sampled and audited. It is important to note 
that Klein is auditing a database by selecting a sample of 
entries in the database and applying a neural network 
analysis to that sample to identify, inter alia, duplicate 
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Applicants' invention relates to preprocessing debit 
invoices before they are entered into the accounts payable 
database. Klein teaches a system for auditing a database to 
identify possibly duplicate entries for future analysis. 

Klein does not perform the same function or achieve the 
same result as applicants' claimed invention. The Examiner 
appears to recognize this point in stating that "Klein does 
not explicitly teach preprocessing of invoices", and "Klein 
does not explicitly teach introduction to and rejection from 
a accounts payable data base." (See page 3 of the Office 
Action.) He then relies on Kline and Geer or Rail, and 
various assertions of "obvious to one of ordinary skill in 
the art..." not supported by reference to any specific 
teaching in the art, to reject applicants claims. 

With respect to Geer. Geer relates to the efficient 
submission of checks and other financial instruments into 
the payment system for collection of funds. The Examiner 
asserts that Geer teaches "preprocessing of original 
invoices before introduction into a database". Applicants 
traverse this characterization. What Geer may properly be 
viewed as teaching is a data capture step, in which 
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information from a check is obtained by electronic scanning 
and communicated electronically into a check clearing system 
by a payee. The whole objective of Geer is to 
electronically capture and transmit check data into the 
payment system so as, in his first example, to avoid the 
necessity of transferring the physical checks from the payee 
to the payor bank, or, in his second example, to allow check 
processing to continue through the payment system without 
waiting for the physical transfer of the checks. These 
checks are received by the payee from a customer together 
with a remittance advice, that is a payment stub or invoice 
copy, so that the check amount can be properly credited to 
the payee customer's account. Geer is not a system for 
receiving invoices for payment, but rather a system for 
receiving checks in payment of invoices. There is no 
teaching in Geer of preprocessing invoices as claimed by 
applicants. Geer can only be fairly interpreted to teach 
that data from the checks are scanned and introduced into 
the payment system for subsequent checking and transaction 
reversal if, for example, it is determined that there are 
insufficient funds to cover the check or a stop order has 
been placed on the check. 



Applicants invention relates to preprocessing of 
invoices to detect and reject duplicate invoices before they 
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make it into the accounting system database. It is 
singularly important to realize that in Geer, a check or 
instrument submitted for collection is well into the 
financial system before action is taken for reversal. 

"In the event of dishonor of a check by a payor bank, 
the process reverses as to the collection of the 
dishonored check, and this information may be 
transmitted electronically back through payment system 
12 (or by more direct means of reversal) to depository 
bank 10 for unwinding the transaction and for debiting 
of the payee's account as to the dishonored check." 
(Geer, at Col. 9, lines 45-50.) 

Thus, to the extent that Geer can be combined with Klein to 
be applied to applicants' invention, Geer teaches away from 
applicants' invention. It is this necessity for unwinding 
of transactions that applicants' invention prevents in the 
context of invoice processing. 

Referring now to applicants claims. 

With respect to claim 1, Klein describes a method of 
analyzing data after the data is entered into a database. 
It does not address the preprocessing of data to eliminate 
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duplicates prior to entering data into a database. In the 
rejection of claim 1, the Examiner references processing 
invoices received from vendor to identify duplicates 
invoices (abstract, column 5 lines 55-65 and column 6 lines 
1 to 5) . This reference does not teach the preprocessing of 
data prior to entering data into the database. These 
references when read in context are offered as examples of 
errors that are commonly found in databases and the 
conventional method of finding duplicate data. There is no 
teaching in Klein of providing a method of finding and 
eliminating the duplicates before they are entered into the 
database. The Examiner's suggests that Geer discloses 
preprocessing of invoices prior to introduction into a 
database (col 5, lines 58-60 & lines 43-45) . That 
conclusion cannot be properly drawn. Geer speaks about a - 
process to eliminate the aggregate loading of all data 
twice, once into the payee's database and a second time into 
the depositories database. Geer's solution allows the data 
to be loaded once and used by both the payee and depository 
bank. It does not speak to the sorting of data for 
duplicates and elimination prior to loading. The Examiner 
also references Klein, indicating that Klein suggests the 
elimination of duplicate data and filtering database (col 26 
lines 40-44 & col 27 lines 22-25) . When these references 
are read in context, it is clear that Klein will provide the 
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user a view of duplicate data, after the duplicates are 
entered into the database, and a prompt asking if the users 
wants to manually eliminate duplicate data, duplicate data 
exceeds the criteria for database accuracy is exceeded. 
Thus, it is not obvious that from Klein and Geer, alone or 
together, one would have developed the solution outlined in 
applicants' claim 1. 

Applicants further assert that the Examiner has used 
impermissible hindsight and applied applicants' own 
teachings against them in concluding that it would have been 
obvious to one of ordinary skill in the art to "introduce 
and reject data from an accounts payable database because 
this would allow filtering and sorting out to be implemented 
as soon as data is available." No reference or teaching on 
the record supports an assertion that it is desirable to 
detect duplicate data before entry to an accounts payable 
database, that is as soon as it is available, or as soon as 
possible, and neither of the art references of Geer and 
Klein suggest such. 

With respect to claim 2, Klein describes a method of 
analyzing data after the data is entered into a database. 
It does not address the preprocessing of data to eliminate 
duplicates prior to entering data into a database. In the 
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rejection of claim 2, the Examiner references auditing 
invoice file for duplicate invoice item (abstract, column 5 
lines 55-65 and column 6 lines 1 to 5) ; creating an 
electronic duplicate data transaction (col 26 lines 37-43) 
and posting to their system only data determined not to be 
duplicate (col 26, lines 32-36) . This reference does not 
teach the preprocessing of data prior to entering data into 
the database. These references, when read in context, are 
offered as examples of errors that are commonly found in 
databases and the conventional method of finding duplicate 
data. There is no indication in Klein of providing a method 
of finding/eliminating the duplicates before they are 
entered into the database. It is not obvious that one would 
have drawn the conclusion from these references to grab EDI 
invoices, and check for and eliminate duplicates before 
loading into an accounts payable database. 

In taking official notice that it is obvious to grab 
data before input into a database, the Examiner is going 
specifically contrary to the teachings of Klein, which is 
sampling data already entered into the database for purpose 
of auditing, and which requires that duplicate or erroneous 
data be "corrected" . In suggesting that inbound EDI invoice 
could be grabbed before inputting it into a database to 
allow detection of duplicate as soon as possible, the 
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Examiner is improperly using applicants disclosure against 
their claim. The art does not suggest or even recognize the 
advantage of detecting duplicates as soon as possible, but 
rather much later, in the course of auditing data already 
entered. It is improper, as the Examiner has done, to take 
official notice of a concept which is at the heart of 
applicants invention: to grab an EDI invoice, and check for 
and eliminate duplicates before loading into an accounts 
payable database. The rejection of claim 2 is based upon an 
untenable series of official notices and conclusions of 
obviousness not supported by the art of record. Applicants 
traverse . 

With respect to claim 3, which depends from claim 2, 
the reading of Klein given by the Examiner to suggest Klein 
teaches the specific steps executed by applicants' claim 3 
to identify duplicate invoices is a hindsight reconstruction 
of Klein based on applicants own disclosure. In rejecting 
claim 3 the Examiner references several sections of Klein, 
and infers that it would be obvious that Klein provides the 
solution that the IBM solution does. The Examiner 
references Kline at column 6 lines 8-10 which, when read in 
context is a statement of the primary goal of the 
conventional method. There is no teaching in Klein of 
providing a method of finding/eliminating the duplicates 
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after grabbing the EDI transaction and before they are 
entered into the database- The reference to the techniques 
used in Klein (col 27 line 54-65 ; col 28 line 28 to 41 and 
lines 44-45) describe pattern matching techniques used 
within the Klein solution, which deals with finding 
duplicates after data is loaded into a database. 

With respect to claim 4, and as previously discussed 
with respect to claim 3, the Examiner states that Klein does 
not explicitly teach grabbing an invoice from a vendor 
before it is input to an accounts payable database and 
creating a transaction to a vendor. Applicants agree. 
However, applicants assert that only impermissible hindsight 
reasoning and the use of applicants disclosure against the 
claim provide any basis for the Examiner to take official 
notice of the grabbing step as is specifically defined by 
applicants. The only art applied in this case against any 
of the claims clearly requires just the opposite: eventual 
detection of erroneous or duplicate data entries require 
that the database be corrected or entries reversed. That is 
precisely the problem in the art (entry of duplicate 
invoices into an accounts payable database that must be 
later reversed) that applicants' invention as claimed 
prevents . 
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With respect to claim 5, the examiner f s reference to 
Klein (col 6 line 8-10) when read in context, is a statement 
of the primary goal of the conventional method. There is no 
teaching in Klein of finding/eliminating duplicates after 
grabbing the EDI transaction and before they are entered 
into the database. Klein col 16 lines 1 to 5 is referring 
to the audit process after the data in entered into the 
database, not the preprocessing of the data before entering 
the data base. The examiner's opinion that it is old and 
well known in the art of data entry to grab data before 
input to a database for the purpose of examination of error, 
is not supported by anything in either Klein or Geer, and 
improperly relies on a bare assertion of obviousness at the 
heart of applicants' claimed invention. The examiner's 
opinion that Klein's neural network auditing approach is the 
same as applicants invention is not correct. Applicants 
invention, as set forth in claim 4, finds duplicate invoices 
before being entered into the database. Klein provides the 
capability for the user to define criteria that creates a 
threshold to be used in an audit of an existing database. 
There is no indication in Klein that a zero sum approach is 
required or used. The Examiner's reference to Klein's (col 
26 line 38-43 and col 26 lines 32-36) warning report and his 
deduction that it would have been obvious to one of ordinary 
skill, to communicate a duplicate invoice rejection message 
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to the vendor, and to refrain from posting the invoice to 
the database is not supported. There is nothing in the art 
of record that supports that conclusion. When these 
references are read in context, it is obvious that the 
duplicate data is already in the database, and that the 
error report goes to a database auditor who has to determine 
if the data is to be corrected. 

With respect to claim 5, the Examiner's reliance upon 
Geer for the preprocessing step is not supported by the 
reference itself. As previously discussed, erroneous 
entries to the check clearance process of Geer must be 
reversed. The preprocessing which Geer dose, and upon which 
the Examiner relies, is merely a data entry step. Checks 
which will not clear are identified much later, and must be 
reversed. The Examiner's reference to Klein (col 5 lines 
55-65, col 6 lines 1 to 5) is taken out of context. This 
reference shows that Klein is discussing the common errors 
found in databases and conventional methods of finding 
duplicate data in databases. The Examiner's reference to 
Klein's (col 26 line 38-43 and col 26 lines 32-36) warning 
report and his deduction that it would have been obvious to 
one of ordinary skill, to communicate a duplicate invoice 
rejection message to the vendor, and to refrain from posting 
the invoice to the database is not supported by the 
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references. When these references are read in context, it 
is obvious that the duplicate data is already in the 
database, and the report goes to the database auditor who 
has to determine if the data is to be corrected. The 
Examiner admits Klein does not teach the concept of 
preprocessing, but refers to Geer in conjunction with Klein 
to reach a conclusion that one of ordinary skill would have 
seen that preprocessing of invoices, rejection of invoices 
to vendors and the use of a zero sum approach are covered 
within Klein and Geer f s teachings. Applicants traverse this 
conclusion. Geer does not teach the elimination of 
duplicate transactions in the context of entering data into 
a database. Geer's teaching are how to eliminate steps in 
the check payment process, not the elimination of duplicate 
transactions at the invoice or check level. 

With respect to claim 6, Klein column 6 lines 8-10 is a 
statement of the primary goal of the conventional method. 
There is no teaching in Klein of providing a method of 
finding/eliminating the duplicates after grabbing the EDI 
transaction and before they are entered into the database. 
The reference to the techniques used in Klein (col 27 line 
54-65; col 28 line 28 to 41 and lines 44-45) describe 
pattern matching techniques used within the Klein solution, 
which deals with finding duplicates after data is loaded 
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into a database. The Examiner f s reference to Klein's (col 
26 line 38-43 and col 26 lines 32-36) warning report and his 
deduction that it would have been obvious to one of ordinary 
skill to communicate a duplicate invoice rejection message 
to the vendor, and to refrain from posting the invoice to 
the database is not supported. When these references in 
Kline are read in context, it is obvious that the duplicate 
data is already in the database, and the error report goes 
to a database auditor, who has to determine if the data is 
to be corrected. The Examiner admits Klein does not teach 
the concept of preprocessing, but references Geer in 
conjunction with Klein to reach a conclusion that one of 
ordinary skill would have seen that preprocessing of 
invoices, rejection of invoices to vendors and the use of a 
zero sum approach are covered within Klein and Geer f s 
teachings. Applicants traverse this conclusion, Geer does 
not teach the elimination of duplicate transactions in the 
context of entering data into a database. Geer f s teaching 
are how to eliminate steps in the check payment process, not 
the elimination of duplicate transactions at the invoice or 
check level. 

Further with respect to claim 6, the Examiner states 
that Klein does not explicitly teach grabbing, does not 
explicitly teach (the steps applicant claims for identifying 
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duplicate invoices), does not explicitly teach communicating 
a duplicate invoice rejection message back to the vendor. 
Nowhere in the art of record is there any teaching of 
rejecting a computer detected duplicate invoice back to a 
vendor before it is entered into the accounts payable 
database. Applicants assert that the only basis on which 
these teachings can be implied from Klein involves 
impermissible hindsight reconstruction of Klein based upon 
applicants own disclosure and requires that the specific 
teachings of Klein be discounted. 

With respect to claim 7 , the Examiner references Klein 
col 6 line 8-10. When read in context, this is a statement 
of the primary goal of the conventional method. There is no 
teaching in Klein of providing a method of finding and 
eliminating the duplicates after grabbing the EDI 
transaction and before they are entered into the database. 
Klein (col 27 line 54-65 ; col 28 line 28 to 41 and lines 
44-45) describes pattern matching techniques used within the 
Klein solution, which deals with finding duplicates after 
data is loaded into a database. The Examiner's reference to 
Klein's (col 26 line 38-43 and col 26 lines 32-36) warning 
report and his deduction that it would have been obvious to 
one of ordinary skill, to communicate a duplicate invoice 
rejection message to the vendor, and to refrain from posting 
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the invoice to the database is not supported. There is 
nothing in the art references of record that would allow 
that conclusion. When these references are read in context, 
it is obvious that the duplicate data is already in the 
database, and the error report goes to the database auditor 
who has to determine if the data is to be corrected. The 
Examiner admits Klein does not teach the concept of 
preprocessing, but references Geer in conjunction with Klein 
to reach a conclusion that one of ordinary skill would have 
seen that preprocessing of invoices, rejection of invoices 
to vendors and use of a zero sum approach covered within 
Klein and Geer f s teachings. Applicants traverse. Geer does 
not teach the elimination of duplicate transactions in the 
context of entering data into a database. Geer's teaching 
are how to eliminate steps in the check payment process, not 
he elimination of duplicate transactions at the invoice or 
check level. 

Further, the Examiner states that Klein does not 
explicitly teach grabbing an invoice before input to an 
accounts payable database, nor identifying duplicate 
invoices (based upon the net sum analysis performed by a 
computer), nor communicating a duplicate invoice rejection 
back to the vendor. Nowhere in the art of record is there 
any teaching of rejecting a computer detected duplicate 
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invoice back to a vendor before it is entered into the 
accounts payable database. Applicants assert that the only 
basis on which these teachings can be implied from Klein 
involves impermissible hindsight reconstruction of Klein 
based upon applicants own disclosure and requires that the 
specific teachings of Klein be discounted. 

With respect to claim 8, the Examiner's reference to 
Klein (col 5 lines 55-65, col 6 lines 1 to 5) is taken out 
of context. A reading in context shows that Klein is 
discussing the common errors found in databases and 
conventional methods of finding duplicate data in databases. 
The Examiner's reference to Klein's (col 2 6 line 38-43 and 
col 26 lines 32-36) warning report and his deduction that it 
would have been obvious to one of ordinary skill, to 
communicate a duplicate invoice rejection message to the 
vendor, and to refrain from posting the invoice to the 
database is not supported. There is nothing in the 
references cited that allows that conclusion. When these 
references are read in context, it is obvious that the 
duplicate data is already in the database, and the error 
report goes to the database auditor, who has to determine if 
the data is to be corrected. The Examiner admits Klein does 
not teach the concept of preprocessing, but references Geer 
in conjunction with Klein to reach a conclusion that one of 
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ordinary skill would have seen that preprocessing of 
invoices and rejection of invoices to vendors using a zero 
sum approach are covered within Klein and Geer's teachings. 
Applicants traverse. Geer does not teach the elimination of 
duplicate transactions in the context of entering data into 
a database. Geer's teaching are how to eliminate steps in 
the check payment process, not the elimination of duplicate 
transactions at the invoice or check level. 

Further with respect to claim 8, the Examiner states 
that Klein does not explicitly teach preprocessing of 
invoices. Applicants agree* However, the Examiner then 
states that Geer discloses such. Applicants traverse. As 
previously noted, Geer relates, at the point cited by the 
Examiner, to data entry into a check clearance system. 
Erroneous checks are not identified until much later, and 
then require that the entry be reversed. Applicants claim 
further recites the specific, computer executed algorithm 
for identifying duplicate invoices. Neither Geer or Klein 
teach such. The suggestion of the Examiner that it would be 
obvious to filter and sort out duplicate invoices before 
entry into an accounts data base as soon as the data is 
available requires an impermissible hindsight reconstruction 
of Klein and/or Geer based upon applicants own disclosure. 
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With respect to claim 9, the Examiner's reference to 
Klein (col 5 lines 55-65, col 6 lines 1 to 5) is taken out 
of context. Correctly read, Klein teaches common errors 
found in databases and conventional methods of finding 
duplicate data in databases. The Examiner's reference to 
Klein's (col 26 line 38-43 and col 26 lines 32-36) warning 
report and his deduction that it would have been obvious to 
one of ordinary skill to communicate a duplicate invoice 
rejection message to the vendor, and to refrain from posting 
the invoice to the database is not supported. When these 
references are read in context, it is obvious that the 
duplicate data is already in the database, and the error 
report goes to the database auditor who has to determine if 
the data is to be corrected. The Examiner admits Klein does 
not teach the concept of preprocessing, but references Geer 
in conjunction with Klein to reach a conclusion that one of 
ordinary skill would have seen that preprocessing of 
invoices and rejection of invoices to vendors using a zero 
sum approach are covered within Klein and Geer's teachings. 
Applicants traverse. Geer does not teach the elimination of 
duplicate transactions in the context of entering data into 
a database. Geer's teaching are how to eliminate steps in 
the check payment process, not the elimination of duplicate 
transactions at the invoice or check level. 
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Further with respect to claim 9, the Examiner states 
that Klein does not explicitly teach grabbing an invoice 
before input to an accounts payable database, nor 
identifying duplicate invoices (based upon the net sum 
analysis performed by a computer) , nor communicating a 
duplicate invoice rejection back to the vendor. Nowhere in 
the art of record is there any teaching of rejecting a 
computer detected duplicate invoice back to a vendor before 
it is entered into the accounts payable database. 
Applicants assert that the only basis on which these 
teachings can be implied from Klein involves impermissible 
hindsight reconstruction of Klein based upon applicants own 
disclosure and requires that the specific teachings of Klein 
be discounted. Applicants claim requires that these steps 
be performed by a computer, and Klein specifically teaches 
that any identification of erroneous data in the database 
being sampled and audited be done by a human. 

Claims 10 and 11 have been rejected under 35 U.S.C. 
103(a) over Geer and further in view of Rail (U.S. Patent 
5, 680, 611) . 

With respect to claim 10, the Examiner's reference to 
Geer (col 7 lines 4 to 25) speaks to the collection of 
checks and payment stubs from individuals who are paying a 
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bill and the comparison of the check to the payment stub and 
storing the payment stub electronically. Geer does not 
teach about receipt of invoices for payment and an accounts 
payable database, Geer (col 9 lines 26-28 & lines 37-44) 
states that information is sorted, grouped and annotated by 
the depository bank, then sent to the payment system who 
then distributes the information to the payees bank, where 
the payees account is debited. Geer does not speak to 
sorting invoices into a credit/debit sequence in the order 
received as set forth in applicant's claim 10, nor to 
posting logic for credit invoices. Geer's teaching are how 
to eliminate steps in the check payment process, not the 
elimination of duplicate transactions at the invoice or 
check level. The assertion that Rail teaches net sum logic 
for evaluating invoices, it in error. Rail deals with the 
creation of bills to be sent for payment, not for invoices 
received for payment. Rail teaches a method that creates a 
"checksum" (specific characteristics of an invoice to be 
sent) and compares the checksum to checksum of previously 
created invoices to ensure a duplicate bill is not mailed. 
There is no teaching of how to prevent invoices to be paid 
from entering the database using a net zero logic. 



With respect to claim 11, which depends from claim 10, 
the Examiner's suggestion that Rail teaches logic rejection 
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of invoices from a vendor is not accurate . Rail does not 
teach the rejection of invoices back to vendors , rather it 
teaches a method to review call records to prevent a record 
from twice appearing on a bill being sent to a customer. 
Its teachings clearly indicate that after matching the call 
records, if a duplicate is found the bill is sent to an 
audit file, not rejected back to a vendor. Rail does not 
speak to what is done with a duplicate record after it is 
sent to this audit file. 

Geer T s teaching are how to eliminate steps in the check 
payment process, not the elimination of duplicate 
transactions at the invoice or check level. 

Applicants request that the rejection of claims 1-11 be 
reconsidered and withdrawn, and the case passed to issue. 



SUMMARY AND CONCLUSION 



Applicants request consideration of the enclosed Rule 
132 Affidavit by James W. Nugent, and urge that the case be 
passed to issue with claims 1-11, a clean set of which is 
appended hereto. 
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If, in the opinion of the Examiner, a telephone 
conversation with applicant (s) attorney could possibly 
facilitate prosecution of the case, he may be reached at the 
number noted below. 



Date: 3fl QgV 2co\ 

Shelley M Beckstrand, P.C. 
Attorney at Law 
314 Main Street 
Owego, NY 13827 

Phone: (607) 687-9913 
Fax: (607) 687-7848 



Sincerely, 



M. W. Beach, et al. 



By 




Shelld^ H Becks 
Reg. No. 24,886 
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